References

• Fixes Access Condition should display on archived item public page #2413
• Requires Display the access status (embargo) for the bitstream DSpace#10294

Description

Display a new embargo badge for the bitstream using the file download component. The badge is only visible if the status is "embargo" and will display a message indicating when the file will be accessible for the current user.

A new configuration (showAccessStatuses) for the bitstream has been added. This configuration is disabled by default.

The access status and the embargo date are retrieved from a new /accessStatus endpoint created in the DSpace PR.

Instructions for Reviewers

• Ensure the badge is not shown by default
• Enable the feature by setting the showAccessStatuses (in the bitstream section) configuration to true
• Ensure the badge is displayed when the bitstream has the embargo status
• The badge should not be displayed for every other statuses (open access and restriction)

How to test

To test, you will need to create/edit specific bitstream policies. To edit policies of an archived item in DSpace:

1. Go to the Item page and connect as administrator
2. Click on the Edit icon on the top right of the Item Page
3. Go the Bitstream tab
4. In the BUNDLE: ORIGINAL section, click on the edit icon of a file
5. At the bottom of the page, click on Edit bitstream's Policies
6. In the policy page, embargo can be define by adding a Start date.

For administrator users:

• No lock and no date regardless of the access status of the icon

For anonymous users:

• Item with one file with active embargo: embargo end date displayed
• Item with one file with embargo end date passed: no date displayed
• Item with one file restricted : no date only lock icon
• Item with multiple file: each file will have its own label
  • One open access (no date)
  • One restricted (no date only lock icon)
  • One embargoed (embargo end date displayed)

List of changes in this PR:

• Added a new "showAccessStatuses" configuration for the bitstream section
• Added a new embargo badge component
• Added a new method to the "access-status-data" service
• Added new unit tests for the embargo badge
• Modified existing unit tests that were impacted

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.